interface/src/routes/Settings.tsx (2)

259-269: agents[0] default-agent selection is still brittle.

agentsData?.agents?.[0]?.id assumes the default agent is always first. If the list order is not guaranteed, this will silently select the wrong agent's config.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@interface/src/routes/Settings.tsx` around lines 259 - 269, The current
defaultAgentId uses a brittle index lookup (agentsData?.agents?.[0]?.id); change
it to search the agents array for a designated default marker instead: use
agentsData?.agents?.find(a => a.isDefault || a.default || a.is_default)?.id and
fall back to the first agent id if no marker exists (i.e.,
agentsData?.agents?.[0]?.id). Update the location where defaultAgentId is
computed (referencing agentsData, agents, defaultAgentId and the useQuery call
to api.agents) so the code picks a true default agent rather than assuming array
order.

---

534-543: Race condition: stale defaultModel shown if defaultAgentConfig hasn't loaded at click time.

If the user opens the edit dialog before the agent-config query resolves, currentChannel is undefined, the currentModel guard is null, and modelInput is set to provider.defaultModel. Because setModelInput is called once at click time and the query result arriving later won't update an already-open dialog, the stale value persists until the dialog is closed and reopened.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@interface/src/routes/Settings.tsx` around lines 534 - 543, The current
click-time logic sets modelInput using defaultAgentConfig which may be undefined
when the agent-config query hasn't resolved, causing a stale
provider.defaultModel to be shown; instead, initialize modelInput without
relying solely on that synchronous value and move the population logic into a
reactive effect: create a useEffect that depends on defaultAgentConfig,
provider.id (and the dialog open state), compute currentChannel =
defaultAgentConfig?.routing?.channel and currentModel as you do (using
isConfigured(provider.id)), and call setModelInput(currentModel ??
provider.defaultModel ?? "") only when the edit dialog is open so the dialog
updates if the query resolves after opening (also ensure you don’t clobber user
edits by gating updates when the user has already modified modelInput).

src/api/providers.rs (2)

962-979: OpenAI ChatGPT OAuth credential deletion does not emit a ProviderSetupEvent.

When credentials are saved (via finalize_openai_oauth, line 416–419), a ProvidersConfigured event is sent. But the deletion path here skips it, which may leave the system in a stale state (e.g., LLM manager still configured for a model whose credentials were just removed). Note: the regular provider deletion path (lines 1010–1017) also omits this, so this is a pre-existing gap—but worth flagging given that the OAuth flow explicitly relies on the event.

♻️ Proposed fix: notify after credential removal

         if let Some(mgr) = state.llm_manager.read().await.as_ref() {
             mgr.clear_openai_oauth_credentials().await;
         }
+        state
+            .provider_setup_tx
+            .try_send(crate::ProviderSetupEvent::ProvidersConfigured)
+            .ok();
         return Ok(Json(ProviderUpdateResponse {
             success: true,
             message: "ChatGPT Plus OAuth credentials removed".into(),
         }));

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/api/providers.rs` around lines 962 - 979, Deletion of OpenAI ChatGPT
OAuth credentials does not emit the ProviderSetupEvent/ProvidersConfigured
event, so after removing the credentials in the openai-chatgpt branch (the block
that calls tokio::fs::remove_file and mgr.clear_openai_oauth_credentials()) send
the same ProvidersConfigured/ProviderSetupEvent used in finalize_openai_oauth;
specifically, after calling clear_openai_oauth_credentials() on
state.llm_manager and before returning the ProviderUpdateResponse, publish/emit
the ProvidersConfigured ProviderSetupEvent (matching the event type and payload
used by finalize_openai_oauth) so listeners know the provider state changed.

---

98-123: API naming still references "Browser" OAuth while the implementation is now device-code flow.

Types like OpenAiOAuthBrowserStartRequest, OpenAiOAuthBrowserStartResponse, and the start_openai_browser_oauth / openai_browser_oauth_status function names reference "browser" OAuth, but the implementation now uses the device-code grant. Consider renaming in a follow-up to reduce confusion for future maintainers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/api/providers.rs` around lines 98 - 123, The public types and handler
names still reference "Browser" OAuth while the flow is actually device-code;
rename OpenAiOAuthBrowserStartRequest, OpenAiOAuthBrowserStartResponse,
OpenAiOAuthBrowserStatusRequest, OpenAiOAuthBrowserStatusResponse and the
handler functions start_openai_browser_oauth and openai_browser_oauth_status to
use "DeviceCode" (e.g., OpenAiOAuthDeviceCodeStartRequest/Response,
OpenAiOAuthDeviceCodeStatusRequest/Response, start_openai_device_code_oauth,
openai_device_code_oauth_status) and update any route registrations, imports,
and usages to match the new names so the API surface and serialization remain
consistent with the current device-code implementation.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

interface/src/routes/Settings.tsx (1)

259-276: ⚠️ Potential issue | 🟡 Minor

Invalidate the new agent-config query after provider changes to avoid stale prefill.

You introduced an agent-config query with staleTime: 10_000, but it isn’t invalidated when providers are updated or after OAuth completes. That can leave the routing model stale for up to 10 seconds, defeating the new prefill behavior.

🔧 Proposed fix — invalidate agent-config alongside agents/overview

setTimeout(() => {
    queryClient.invalidateQueries({ queryKey: ["agents"] });
+   queryClient.invalidateQueries({ queryKey: ["agent-config"] });
    queryClient.invalidateQueries({ queryKey: ["overview"] });
}, 3000);

setTimeout(() => {
    queryClient.invalidateQueries({ queryKey: ["agents"] });
+   queryClient.invalidateQueries({ queryKey: ["agent-config"] });
    queryClient.invalidateQueries({ queryKey: ["overview"] });
}, 3000);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@interface/src/routes/Settings.tsx` around lines 259 - 276, The new
"agent-config" query can stay stale for up to 10s because it's not invalidated
when providers change or OAuth flows complete; update the providers change and
OAuth completion handlers to call the React Query invalidation for the
agent-config key (e.g., invalidateQueries(["agent-config"]) or
invalidateQueries(["agent-config", defaultAgentId]) via the queryClient) so that
the defaultAgentConfig fetched by useQuery (queryKey ["agent-config",
defaultAgentId] / queryFn api.agentConfig) is refreshed immediately after
provider updates or OAuth completes, ensuring the routing model prefill is not
stale; place the invalidation alongside the existing invalidation calls for
agents/overview so it runs in the same update flow.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

interface/src/routes/Settings.tsx (2)

287-295: ⚠️ Potential issue | 🟡 Minor

Effect still unconditionally overwrites in-progress user input.

The past review proposed guarding setModelInput against overwriting when the user has already edited the field (e.g. prev === providerDefault || !prev). This remains unaddressed — if the user starts typing before defaultAgentConfig resolves, their edits are silently replaced.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@interface/src/routes/Settings.tsx` around lines 287 - 295, The effect
unconditionally calls setModelInput when defaultAgentConfig arrives, overwriting
user edits; modify the useEffect (the one referencing editingProvider,
defaultAgentConfig and calling setModelInput) to use the functional updater form
setModelInput(prev => { if (prev !== undefined && prev !== '' && prev !==
providerDefault) return prev; return currentChannel; }) so it only replaces the
input when the previous value is empty or still equals providerDefault; keep the
same dependency array behavior but perform this guarded update using
currentChannel, editingProvider and providerDefault names to locate the code.

---

269-282: ⚠️ Potential issue | 🟡 Minor

["agent-config"] is still never invalidated after mutations — pre-populated model stays stale.

The past review flagged updateMutation.onSuccess (lines 318–321) and monitorOpenAiBrowserOAuth (lines 419–421). Both still omit queryClient.invalidateQueries({ queryKey: ["agent-config"] }). Additionally, ConfigFileSection.updateMutation.onSuccess (lines ~1503–1506) now also has this gap — a raw config edit can change routing, yet the ["agent-config"] cache is never busted there either.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@interface/src/routes/Settings.tsx` around lines 269 - 282, The
["agent-config"] cache is never invalidated after mutations, causing stale
pre-populated model data; update all mutation success handlers to call
queryClient.invalidateQueries({ queryKey: ["agent-config"] }) so the agent
config is refetched — specifically add this invalidation in
updateMutation.onSuccess, in monitorOpenAiBrowserOAuth's success path, and in
ConfigFileSection.updateMutation.onSuccess so any changes (including raw config
edits that can change routing) refresh the cached ["agent-config"] data used by
the useQuery that depends on defaultAgentId.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro